System and method for operating system event redirection

ABSTRACT

The disclosure provides an approach for transferring an object between a virtualized desktop infrastructure (VDI) client running on a client device and a remote virtual machine (VM) connected to the VDI client through a network. The method includes receiving, at the client device, an input corresponding to a drag and drop operation of an object between the client device and a remote desktop displayed at the client device, the remote desktop running on the remote VM. The method includes transferring one or more commands corresponding to the drag and drop operation from the client device to the remote VM or from the remote VM to the client device via a first channel. The method also includes transferring the object from the client device to the remote VM or from the remote VM to the client device via a second channel.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. provisional application havingSer. No. 62/779,257, filed on Dec. 13, 2018, which is herebyincorporated by reference herein in its entirety.

BACKGROUND

In a virtual desktop infrastructure (VDI) environment, objects such asplain text and images can be shared between a local client device and aremote desktop or remote application running on a remote device anddisplayed at the local client device by using a clipboard feature (i.e.,copy and paste), meaning the objects are shared between the local clientdevice and the remote device. In order to copy files or folders betweena local client device and a remote desktop or application of a remotedevice displayed at the local client device, a client drive redirection(CDR) feature is used, which may require multiple steps to transfer thefile between the local client device and the remote device. The userexperience would be improved with a simpler system for copying filesand/or folders between the local client device and the remote device.Therefore what is needed is an improved method for a user to share filesand/or folders between a local client device and a remote desktop orapplication of the remote device.

In addition to sharing files and/or folders, users may wish to sharedata of different formats between a local client device and a remotedesktop application. If it's possible to share data of differentformats, users and/or administrators may also wish to implement rules tomanage sharing for the different formats. Users may also want to useclient devices with different operating systems than the operatingsystem installed on the remote device. These features are not found incurrent VDI environments, and therefore what are needed are systems andmethods for implementing these features.

SUMMARY

A method of transferring a file or other object between a virtualizeddesktop infrastructure (VDI) client running on a client device and aremote virtual machine (VM), wherein the remote VM is connected to theVDI client through a network. The method includes receiving, at theclient device, an input corresponding to a drag and drop operation of anobject between a local storage of the client device and a remote desktopdisplayed at the client device, the remote desktop running on the remoteVM. The method also includes, based on the input, transferring one ormore commands corresponding to the drag and drop operation from theclient device to the remote VM or from the remote VM to the clientdevice via a first channel. The method also includes, based on theinput, transferring the object from the client device to the remote VMor from the remote VM to the client device via a second channel.

Further embodiments include a non-transitory computer-readable storagemedium storing instructions that, when executed by a computer system,cause the computer system to perform the method set forth above.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a block diagram of a virtualized desktop infrastructuresystem in which one or more embodiments of the present invention may beimplemented.

FIGS. 2A and 2B depict a workflow diagram for transferring drag and dropcommands using a first channel and a second channel.

FIG. 3 depicts a workflow diagram for transferring a dragged file orfolder using a CDR channel.

FIG. 4 depicts a method for transferring a file or folder from a clientto an agent using a temporary folder.

FIG. 5 depicts a method for transferring a file or folder from an agentto a client using a temporary folder.

FIG. 6 depicts a method for transferring a file or folder from a clientto an agent without using a temporary folder.

FIG. 7 depicts a method for transferring a file or folder from an agentto a client without using a temporary folder.

To facilitate understanding, identical reference numerals have beenused, where possible, to designate identical elements that are common tothe figures. It is contemplated that elements disclosed in oneembodiment may be beneficially utilized on other embodiments withoutspecific recitation.

DETAILED DESCRIPTION

The present disclosure provides an approach for operating system (OS)event redirection. By using OS event redirection, a “drag and drop”(DnD) user experience can be implemented that allows files and/orfolders to be shared between a local client device and a remote desktopor application of a remote device. DnD is a common feature where a user“grabs” a representation of an object (such as a file) and drags it to adifferent location using a user interface (UI). For example, the UIrepresents a file system that allows a representation of an object to bedragged from a portion of the UI representing one location in the filesystem to another portion of the UI representing another location in thefile system. Underlying software, such as an operating system (OS),correspondingly transfers the object from the one location to the otherlocation. In certain embodiments, the UI further allows an object to bedragged from a local storage of a local client device to a remotedesktop or application of a remote device displayed at the local clientdevice. For example, a representation of the object can be dragged tothe displayed remote desktop or application at the local client device.OS event redirection causes the object to be transferred (e.g., copied)from the local client device to the remote device for access by theremote desktop or application. With OS event redirection, users canconveniently drag and drop files, folders, or other objects betweenlocal and remote devices using logical or virtual channels configured onone or more physical interfaces. Different virtual channels can havedifferent latencies or bandwidths, due to the channels being allocateddifferent resources of the one or more physical interfaces, which makessome channels more suitable for certain operations than other channels.Two virtual channels can be leveraged to implement OS event redirection.Using multiple channels allows commands to be transferred on a differentchannel than the dragged objects. Therefore if large objects are draggedand dropped, requiring a long time for the transfer to complete, thetransfer does not interfere with commands because the commands are on aseparate channel. First, in one embodiment, a first channel is used totransfer the DnD workflow commands between the local and remote devices,such as a control message channel. Then, a second channel is used totransfer the dragged files, such as a CDR channel. The CDR channel canbe a high-speed channel so that the dragged objects are transferred morequickly. OS event redirection also allows the remote desktop orapplication side of the remote device to simulate an OS event to makethe OS event look like the event is happening locally at the localclient device. In another embodiment, the channel used to transfer theDnD workflow commands is also used to transfer the dragged object orfiles. In other embodiments, size and/or format controls are implementedon the dragged objects or files.

FIG. 1 depicts a block diagram of a virtualized desktop infrastructure(VDI) system 100 in which one or more embodiments of the presentinvention may be implemented. VDI system 100 comprises at least oneclient device 104 and a data center 102, connected by a network 146.Network 146 may be, for example, a direct link, a local area network(LAN), a wide area network (WAN) such as the Internet, another type ofnetwork, or a combination of these.

Client device 104 is a physical device, such as a general purposedesktop computer or mobile computer. A mobile computer may be, forexample, a laptop, a mobile phone, or a tablet computer. Client device104 includes VDI client 134 and OS 132, with VDI client 134 running ontop of OS 132. OS 132 may be a standard, commodity operating system.

VDI client 134 is a user-side interface of a virtualized desktop runningon one of virtual machines (VMs) 120. As used herein, a “virtualizeddesktop” or “remote desktop” is a desktop running on one of VMs 120 thatis displayed remotely on client device 104, as though the remote desktopwere running on client device 104. By opening VDI client 134, a user ofclient device 104 accesses, through network 146, a remote desktoprunning in remote data center 102, from any location, using clientdevice 104. Frames of the remote desktop running on VM 120 aretransmitted to VDI client 134 at a certain frame rate using a desktopdelivery protocol such as VMware® Blast™, or Microsoft® Remote DesktopProtocol (RDP)™.

After transmission, the frames are displayed on client device 104 forinteraction by the user. Client device 104 sends user inputs to VM 120for processing on VM 120 of data center 102, taking processing load offof client device 104. Such centralized and automated management ofremote desktops provides increased control and cost savings. VDI client134 may be, for example, VMware® View™, or a special purpose thin clientsuch as those available from Dell, HP, NEC, Sun Microsystems, Wyse, andothers.

Data center 102 includes host(s) 105, a virtualization manager 130, agateway 136, a management network 128, and a data network 118. Althoughthe management and data network are shown as separate physical networks,it is also possible in some implementations to logically isolate themanagement network from the data network using different VLANidentifiers. Each of hosts 105 may be constructed on a server gradehardware platform 106, such as an x86 architecture platform. Forexample, hosts 105 may be geographically co-located servers on the samerack.

Host 105 is configured to provide a virtualization layer, also referredto as a hypervisor 116, that abstracts processor, memory, storage, andnetworking resources of hardware platform 106 into multiple VMs 120 ₁ to120 _(N) (collectively referred to as VMs 120 and individually referredto as VM 120) that run concurrently on the same host. Hypervisor 116 mayrun on top of the operating system in host 105. In some embodiments,hypervisor 116 can be installed as system level software directly onhardware platform 106 of host 105 (often referred to as “bare metal”installation) and be conceptually interposed between the physicalhardware and the guest operating systems executing in the virtualmachines. In some implementations, the hypervisor may comprise systemlevel software as well as a “Domain 0” or “Root Partition” virtualmachine, which is a privileged machine that has access to the physicalhardware resources of the host. In this implementation, one or more of avirtual switch, virtual tunnel endpoint (VTEP), etc., along withhardware drivers, may reside in the privileged virtual machine. Althoughthe disclosure is described with reference to VMs, the teachings hereinalso apply to other types of virtual computing instances (VCIs), such ascontainers, Docker containers, data compute nodes, isolated user spaceinstances, namespace containers, and the like. In certain embodiments,VMs 120 may be containers that run on host 105 without the use of ahypervisor. One example of a hypervisor 116 that may be used is a VMwareESXi™ hypervisor provided as part of the VMware vSphere® solution madecommercially available from VMware, Inc. of Palo Alto, Calif.

Each VM 120 includes a guest OS 122, one or more applications 126, and aVDI agent 124. Application(s) 126 and VDI agent 124 run on top of guestOS 122. Guest OS 122 may be a standard, commodity operating system. Anapplication 126 may be any software program, such as a word processingprogram.

VDI agent 124 is a desktop virtualization program that connects to VDIclient 134 of client device 104, through network 146. The connectionbetween VDI agent 124 and VDI client 134 may be authenticated, such asthrough a username and password combination pertaining to client device104 or to a user of client device 104. VDI agent 124 transmits, to VDIclient 134, image frames of the remote desktop running on VM 120 thatcontains VDI agent 124. An image frame includes information onappearance of the remote desktop running on VM 120, and that informationincludes pixel color and location information. In addition to an imageframe, VDI agent 124 may also transmit metadata of that frame to VDIclient 134. The metadata may include x and y coordinate locations of amouse cursor, x and y coordinates and size of windows of application(s)126 open on the remote desktop, which application(s) 126 are running onand/or displayed on the remote desktop of VM 120, and other information.

Hardware platform 106 of each host 105 includes components of acomputing device such as one or more processors (CPUs) 108, systemmemory 110, a network interface 112, storage system 114, a host busadapter (HBA) 115, and other I/O devices such as, for example, a mouseand keyboard (not shown). CPU 108 is configured to execute instructions,for example, executable instructions that perform one or more operationsdescribed herein and that may be stored in memory 110 and in storage114. Network interface 112 enables host 105 to communicate with otherdevices via a communication medium, such as network 118 or network 128.Network interface 112 may include one or more network adapters, alsoreferred to as Network Interface Cards (NICs). Storage system 114represents persistent storage devices (e.g., one or more hard disks,flash memory modules, solid state disks, and/or optical disks). Host busadapter (HBA) couples host 105 to one or more external storages (notshown), such as a storage area network (SAN). Other external storagesthat may be used include network-attached storage (NAS) and othernetwork data storage systems, which may be accessible via NIC 112.

System memory 110 is hardware allowing information, such as executableinstructions, configurations, and other data, to be stored andretrieved. Memory 110 is where programs and data are kept when CPU 108is actively using them. Memory 110 may be volatile memory ornon-volatile memory. Volatile or non-persistent memory is memory thatneeds constant power in order to prevent data from being erased.Volatile memory describes conventional memory, such as dynamic randomaccess memory (DRAM). Non-volatile memory is memory that is persistent(non-volatile). Non-volatile memory is memory that retains its dataafter having power cycled (turned off and then back on). Non-volatilememory is byte-addressable, random access non-volatile memory.

Virtualization manager 130 communicates with hosts 105 via a network,shown as a management network 128, and carries out administrative tasksfor data center 102 such as managing hosts 105, managing VMs 120 runningwithin each host 105, provisioning VMs, migrating VMs from one host toanother host, and load balancing between hosts 105. Virtualizationmanager 130 may be a computer program that resides and executes in acentral server in data center 102 or, alternatively, virtualizationmanager 130 may run as a virtual appliance (e.g., a VM) in one of hosts105. One example of a virtualization manager is the vCenter Server™product made available from VMware, Inc.

Gateway 136 provides VMs 120 and other components in data center 102with connectivity to network 146. Gateway 136 may manage external publicIP addresses for VMs 120, route traffic incoming to and outgoing fromdata center 102, and provide networking services, such as firewalls,network address translation (NAT), dynamic host configuration protocol(DHCP), and load balancing. Gateway 136 uses data network 118 totransmit data network packets to hosts 105. Gateway 136 may be a virtualcomputing instance, a physical device, or a software module runningwithin host 105. Gateway 136 may include two gateways: a managementgateway for management network 128 and a data gateway for data network118.

FIGS. 2A and 2B depict a workflow diagram 200 for transferring DnDcommands using a first virtual channel and a second virtual channel. Inone example embodiment, this first channel is a control message virtualchannel. Diagrams 200A and 200B illustrate a user 202 that implements adrag and drop operation by performing drag and drop functions with aninput device such as a mouse, touch-screen, etc., of a client device,such as client device 104. The actions performed on the client sideshown as performed by elements 202-216 are illustrated on the left sideof diagram 200 and may be performed by VDI client 134 and/or OS 132running on client device 104 of FIG. 1, while the actions performed onthe agent or remote side shown as performed by elements 218-228 areillustrated on the right side of diagram 200 and may be performed by VDIagent 124, Apps 126, and/or Guest OS 122 running on host 105 of FIG. 1.In certain embodiments, DnD operations are facilitated with ObjectLinking and Embedding (OLE). OLE is a Microsoft® technology thatfacilitates the sharing of application data and objects written indifferent formats from multiple sources. OLE is used for DnD andclipboard operations. OLE creates data sources and objects that theoperating system uses to perform these operations. An OLE implementationperforms DnD operations by creating a DnD data object 208 correspondingto the object being dragged, a DnD drop source object 206, and a DnDdrop target object 214 on the client side. OLE also creates objects onthe agent side, which includes DnD drop source 220, DnD data object 222,and DnD drop target 228. The use of these OLE objects in an exampleoperation is described in further detail below. Though certain aspectsare described with respect to OLE of OS 132, it should be understoodthat other technologies may similarly be used for other types of OS.

In this example, a user 202 at client device 104 uses the mouse toselect, using a UI, representations of one or more files or foldersstored locally at the client device 104 by holding down the mouse on theselected representations of the one or more files or folders. The userthen drags the selected representations with the mouse to a portion ofthe UI displayed at the client device 104 displaying a remote desktop orremote application of VM 120 and drops the representations of theselected one or more files or folders at the remote desktop orapplication by releasing the mouse. The files or folders are thentransmitted to the remote device, e.g., host 105, from the client device104 for access by the remote desktop or application on VM 120. With theembodiments described herein, and from the perspective of the user, theexperience for dragging and dropping local files/folders on the clientside to a remote desktop or application is the same as local drag anddrop within a client device.

The method illustrated in FIGS. 2A and 2B operates as follows. Themethod begins in FIG. 2A where a user 202 initiates a drag at step 230in a source application 204 (e.g., VDI client 134) on the client side.For example, a user 202 selects a file with a mouse and then drags thefile (e.g., as represented in a file system) stored locally with respectto client device 104 using a UI provided by OS 132 of client device 104to a virtual desktop of VM 120 on host 105 displayed at client device104 by VDI client 134. OLE in OS 132 creates DnD Drop Source 206 at step231. DnD Data Object 208 is created by OLE in OS 132 at step 232. DnDData Object 208 enables data transfer and notification of changes indata. For a file or folder, DnD Data Object 208 holds the file paths.For other data formats (like image or text), DnD Data Object 208 holdsthe data itself. A Do drag and drop operation is called at step 233 toVDI client 134 to begin a drag and drop operation. OS DnD Interface 212in OS 132 is an OLE function that handles DnD interactions betweenapplications and the OS. OS DnD Interface 212 receives the Do drag anddrop operation and a Drag Enter is sent in step 234 to DnD Drop Target214, which is an object also created by OLE for facilitating DnDoperations. At step 235, Drag Enter message is sent from DnD Drop Target214 to Target App/Remote Desktop 216 at VDI client 134.

To continue the DnD operation, a Drag Enter message 236 is sent from theclient side to DnD Server 218 in guest OS 122 at VM 120 on the remoteside. At step 237 a detection window is moved and a mouse up action issimulated to simulate the drag event on the remote desktop. At step 238OLE creates a mirror DnD Drop Source 220 object on the remote side at VM120. A mirror DnD Data Object interface 222 on the remote side iscreated by OLE in step 239. At step 240 the DnD Server 218 in guest OS122 simulates a mouse down action. OS DnD Interface 226 in guest OS 122receives the Do drag and drop operation 241.

On the client side, at OS 132, a Drag Over event 242 occurs and a DragOver Message is sent at step 243 from DnD Drop Target 214 to TargetApp/Remote Desktop 216 at client device 104. In one example embodiment,an icon is displayed to the user 202 on client device 104 to inform theuser whether the dragged object can be dragged to a specific location.That is, a user may see an icon like a plus sign (+) if the user isallowed to drag the object to a certain location. If the user cannotdrag the object to that location, the user may see a different icon,such as an X. A Move Mouse message 244 is transmitted from OS 132 on theclient side to the DnD Server 218 on the remote side. Move Mouse message244 redirects the Drag Over event 242 to the remote side. DnD Server 218sets a cursor position on a user interface representing guest OS 122 atstep 245. A Drag Enter message 246 is sent from OS DnD Interface 226 inguest OS 122 to DnD Drop Target 228. DnD Drop Target 228 is on OLEobject used for drag and drop operations on the remote side. DnD DropTarget 228 enumerates the format in which data is stored in DnD DataObject 222 at steps 247 and 248, and an accept or reject message 249 isgenerated on the remote side. This message 249 instructs client device104 as to whether the remote side accepts or rejects the drag event.

Feedback to user 202 is sent from the remote side to the client side. OSDnD Interface 226 on the remote side sends a Give Feedback message 250to DnD Drop Source 220, which sends an Update Drop Effect message 251 toDnD Server 218 in guest OS 122. An Update Drop Effect Message 252 istransmitted to client device 104. An accept or reject message isforwarded at steps 253 and 254 to OS DnD Interface 212 in OS 132 on theclient side. Step 254 and later steps are illustrated on FIG. 2B. Cursorfeedback 255 is transmitted to source app 204 at OS 132 of client device104 to display the cursor position to the user, while a Query ContinueDrag 256 is sent to determine if a drag continues on the client side(i.e., to determine if the user has completed the drag operation and“dropped” the dragged object).

User 202 then performs a drop action 257. The drop action can beperformed by the user releasing a mouse button once the user 202 hasdragged the selected file or folder to the target location. OS DnDInterface 212 in OS 132 transmits the drop action to DnD Drop Target 214at step 258. DnD Drop Target 214 receives data regarding the draggedobject (in particular, the format of the object) from DnD Data Object208 at step 259 and the actual data content is retrieved at step 260with the use of OS Medium Exchange 210 to retrieve the data from thedisk. At step 261, a Drop message is sent to Target App 216.

The Drop message 262 is then transmitted from the client side to theremote side. A mouse up operation is simulated in guest OS 122 on theremote side at step 263. The Drop Message is then transmitted to OS DnDInterface 226 in guest OS 122 at step 264, and then sent to DnD DropTarget 228 at step 265. A Get Data message is sent at step 266 from DnDDrop Target 228 to retrieve data from DnD Data Object 222.

A Drop Done message 267 is transmitted from guest OS 122 at the remoteside to OS 132 at the client side. Target pp 216 in OS 132 accesses thedragged object's data on disk from OS Medium Exchange 210 at step 268.At step 269, the file or other dragged object is copied from the clientside to the remote side via a second channel, such as the CDR channel inone embodiment. The remote side waits until the copy operation iscomplete. When the copy operation is finished, a Get Files Done message270 is transmitted from the client side to the remote side. A Set Eventmessage 271 is sent from DnD Server 218 in guest OS 122 to DnD DataObject 222. Data content of the transferred object is retrieved from OSMedium Exchange 224 at step 272, and DnD Drop Target 228 receives thedragged and dropped file at step 273.

FIG. 3 is a workflow diagram 300 for transferring a dragged file,folder, or other object using a client drive redirection (CDR) channel.When dragging a file from client device 104 to an agent, such as VDIagent 124, the folder containing the dragged file is shared to theagent. When dragging a file from agent to client, a temporary folder iscreated on the client side and shared to the agent as the drop targetfolder. The actions in FIG. 3 may be performed by VDI client 134 and/orOS 132 running on client device 104 of FIG. 1, or may be performed byVDI agent 124, Apps 126, and/or Guest OS 122 running on host 105 of FIG.1, depending on the direction the file is dragged. In this example, theuser drags an object from client device 104 to a remote desktop of VM120. A user 302 initiates a drag at step 322 by selecting a file orfolder at client device 104 by clicking and holding a mouse button, forexample. A DragEnter event 324 is transmitted from OS DND Interface 304in OS 132 to DND Client 306 in OS 132. At step 326 the folder containingthe dragged object is shared from DnD Client 306 to CDR Client 308 in OS132.

At step 328, the folder that contains the dragged objects is sharedbetween CDR Client 308 and CDR Server 312 in guest OS 122. Then, whenuser 302 has dragged the files to the desired destination at the remotedesktop of VM 120, user 302 drops the files at step 330. The dropnotification is transmitted to DnD Client 306 from OS DnD Interface 304at step 332. File and/or folder paths are transmitted to a DnD Server310 in guest OS 122 via step 334. Then, the copy process for the filesand/or folders begins at step 336.

During the copy process, progress data is communicated from the remoteside to client device 104 so user 302 can view the copy progress. Thisprogress data, as shown, is transmitted from DnD Server 310 at theremote side to DnD Client 306 at step 338. At step 340, the client userinterface (UI) is notified to display the progress to user 302 at clientdevice 104.

When the file transfer is finished, a Done Event message is generated atDnD Server 310 at the remote side and transmitted to DnD Client 306 inOS 132 at step 342. Then, at step 344 the client uses a DnD remoteprocedure call (RPC) to notify the server side OS DnD component toaccess the files and finish the drop operation. In some embodiments, thedragged file is first copied to a temporary folder on the remote side.Then, after the copy is complete, the file is copied from the temporaryfolder to the actual destination folder. In other embodiments, thedragged file is copied directly to the actual destination without usinga temporary folder.

Three example methods are illustrated to show the progress window to theuser at client device 104. A first method is to display the progresswindow using an RMKS (remote mouse, keyboard, screen) process. Anadvantage of this solution is that it is simple to implement when a newplatform is supported in VDI. A second method is to display the progresswindow in a client process in OS 132 at client device 104. This methodprovides a flexible solution to showing the progress in the userinterface at the client device 104. A third method is to manage the copyprogress window on the remote side in guest OS 122. With this thirdmethod, the client side only needs to display a simple window at clientdevice 104, such as part of the remote desktop frames, and there islimited communication needed between the client and agent side. However,the third method may be a more complex implementation in someembodiments.

FIG. 4 is a diagram 400 illustrating a method for transferring a file orfolder from a client to an agent using a temporary folder. A user 402,Client 404 (such as client device 104), and Agent 406 (such as VM 120)are illustrated. Client 404 comprises a DnD Client 408 in OS 132. Agent406 comprises a DnD Server 410 in guest OS 122 and an Agent OS 412, suchas guest OS 122. The steps illustrated in diagram 400 may be performedin any suitable order.

In this example, user 402 wants to drag and drop a file from client 404to agent 406. At step 414, the user drags the file that the user wantsto transfer from the client side to the target location on the agentside and then drops the file by releasing a mouse button. The file canbe dropped into a file manager application (e.g., a file explorer suchas Windows Explorer) on the remote side or into an application 126running on the remote side. At step 416, DnD Client 408 notifies DnDServer 410 that a file has been dropped from Client 404 to Agent 406.This notification can be transmitted on the first channel, such as acontrol message channel. At step 418, Client 404 shares the sourcefolder for the dragged file with agent 406 by CDR. Also, at this timethe client UI on client device 104 shows user 402 that the progress is0%.

At step 420, DnD Server 410 copies the source file to a temporary folderat agent 406. The file is transferred using a second channel, such asCDR. During this copy process, Agent 406 notifies Client 404 of theprogress of the copy operation at step 422 using the control messagechannel. The UI at Client 404 shows the copy progress at step 424. Afterthe copy is finished, DnD Server 410 returns the file path of thetemporary folder to Agent OS 412 at step 426. At step 428, Client 404 isnotified by Agent 406 to hide the progress window. At step 430, clientUI hides the progress window.

If the file is copied to the file manager application at Agent 406, themethod proceeds to step 432 where the dragged file is copied from thetemporary folder to the target folder. If the file is copied to a remoteapplication at Agent 406, the method proceeds to step 434 where Agent OS412 uses the dragged file in the temporary folder directly. At step 436,Client 404 unshares the drag source folder.

FIG. 5 is a diagram 500 illustrating a method for transferring a file orfolder from an agent to a client using a temporary folder. A user 502,Client 504 (such as client device 104), and Agent 506 (such as VM 120)are illustrated. Client 504 comprises a DnD Client 508 and a Client OS512 (such as OS 132). Agent 506 comprises a DnD Server 510 in guest OS122. The steps illustrated in diagram 500 may be performed in anysuitable order.

In this example, user 502 wants to drag and drop a file from Agent 506to Client 504. At step 514, the user drags the file that the user wantsto transfer from the remote side to the target location on the clientside and drops the file. The file can be dropped in the client OS's filemanager application or an application running in OS 132 on Client 504.

At step 516, DnD Server 510 is notified via the control message channelthat a file has been dragged and dropped from Agent 506 to Client 504.At step 518, a temporary folder in Client OS 512 is shared by CDR, andthe client UI shows an initial progress of 0%. At step 520, DnD Server510 copies the drag source file to the shared temporary folder. Duringthe copy process, Agent 506 notifies Client 504 of the copy process atstep 522, and the client UI at client device 104 shows the copy progressat step 524.

At step 526, the copy is finished. Agent 506 notifies Client 504 to hidethe progress window on the UI of client 504 at step 528, and the Client504 UI hides the progress window at step 530. At step 532, DnD Client508 returns the file path under the temporary folder to the Client 504OS. If the file is copied to the file manager application, the methodproceeds to step 534 where the dragged file is copied from the temporaryfolder to the target folder. If the file is copied to a remoteapplication, the method proceeds to step 536 where Client OS 512 usesthe dragged file in the temporary folder directly. At step 538, Client504 unshares the temporary folder.

The two workflows described in FIGS. 4 and 5 copy the dragged file firstto a temporary folder and then to a target folder. If the file that iscopied is large, these two workflows need additional time to completethe two copies. The workflows described in FIGS. 6 and 7 below avoid theadditional file copy operation.

FIG. 6 is a diagram 600 illustrating a method for transferring a file orfolder from a client to an agent without using a temporary folder. Auser 602, Client 604 (such as client device 104), and Agent 606 (such asVM 120) are illustrated. Client 604 comprises a DnD Client 608 in OS 132of client 604. Agent 606 comprises an Agent OS 612 and a DnD Server 610in Agent OS 612 (such as guest OS 122). The steps illustrated in diagram600 may be performed in any suitable order.

In this example, user 602 wants to drag and drop a file from Client 604to Agent 606. At step 614, the user drags the file that the user wantsto transfer from the client side to the target location on the remoteside and then drops the file at a representation of the target locationin a user interface. The file can be dropped into the file managerapplication on the remote side or into an application 126 running on theremote side. At step 616, DnD Client 608 notifies DnD Server 610 that afile has been dropped from Client 604 to Agent 606. At step 618, Client604 shares the source folder for the dragged file with Agent 606 by CDR.Also, at this time the client UI at client device 104 shows user 602that the progress is 0%.

At step 620, DnD Server 610 detects the drop target from thenotification information at step 616. If the drop target is a filemanager application in agent OS 612, the method proceeds to step 622where DnD Server 610 retrieves the folder path that the file managerapplication is pointing to and copies the drag source file at Client 604from the shared folder to the target folder. In addition, at step 624Client 604 is notified of the copy progress from Agent 606. At step 626,the Client 604 UI shows the copy progress.

If the drop target is an application on Agent 606 (such as application126) instead of the file manager application, the method proceeds tostep 628 where the dragged file is accessed in the shared folderdirectly. At step 630, DnD Server 610 returns the file path in theshared folder to Agent OS 612. In addition, Client 604 is notified instep 632 to hide the copy progress UI window in step 634.

Returning to the situation where the drop target is the file managerapplication, the copy operation in step 622 is finished at step 636.Client 604 is notified at step 638 to unshare the drag source folder. Atstep 640, Client 604 unshares the folder. At step 642, DnD Server 610notifies Client 604 to hide the progress UI window. Therefore in thisworkflow, the dragged and dropped file is copied directly to Agent 606without using a temporary folder.

FIG. 7 is a diagram 700 illustrating a method for transferring a file orfolder from an agent to a client without using a temporary folder. Auser 702, Client 704 (such as client device 104), and Agent 706 (such asVM 120) are illustrated. Client 704 comprises a Client OS 712 (such asOS 132) and a DnD Client 708 in Client OS 712. Agent 706 comprises a DnDServer 710 in an Agent OS such as guest OS 122. The steps illustrated indiagram 700 may be performed in any suitable order.

In this example, user 702 wants to drag and drop a file from Agent 706to Client 704. At step 714, the user drags the file that the user wantsto transfer from the remote side to the target location on the clientside and drops the file at a representation of the target location in auser interface. The file can be dropped in client OS 712's file managerapplication or an application on Client 704.

At step 716, DnD Server 710 is notified via the control message channelthat a file has been dragged and dropped from Agent 706 to Client 704.In the drop event, DnD Client 708 detects the drop target at step 718.If the drop target is a file manager application in OS 132, DnD Client708 retrieves the folder then the file manager application is pointingto, then shares the target folder with Agent 706 via CDR as shown instep 720. If the drop target is an application, then in step 722 atemporary folder in the client OS is shared via CDR and the client UI atclient device 104 shows the progress is 0%.

Next, DnD Server 710 copies the dragged source file to the sharedtemporary or target folder in step 724. In step 726, Client 704 isnotified of the copy progress by DnD Server 710, and in step 728 theclient UI shows the copy progress.

The copy operation is finished at step 730. DnD Server 710 notifiesClient 704 to hide the progress window in step 732, and the client UIhides the progress window in step 734. If the drop target is anapplication, DnD Client 708 returns the shared temporary file path toClient OS 712 in step 736.

If the drop target is the file manager application, the Client 704 droptarget folder is unshared in step 738. If the drop target is anapplication, the temporary folder is unshared in step 740.

When dragging an object from a remote desktop or remote application,such as application 126, to a client device 104, the DnD feature needsto detect whether a real DnD operation is occurring. To implement thiscapability, one embodiment uses hidden detection windows in guest OS122. For example, a drag detection window for VDI is used to detectwhether the user is performing a DnD operation from the remote desktopto client device 104. In another example, a drag detection window for aremote application 126 is used to detect whether a user is performing aDnD operation from the remote application 126 to client device 104.Because remote desktops may use different coordinate systems than remoteapplications, separate detection windows may be used to detect thedifferent types of drag operations in an embodiment. Additionally, ahidden message window can be used to deal with internal messages sentfrom the detection window during DnD operations.

When the user attempts to drag a file from a remote VM 120 to clientdevice 104, an “ungrab” operation has to be handled. In one embodiment,the steps to perform an ungrab operation are as follows. First, a RMKS(remote mouse, keyboard, screen) process in OS 132 at client device 104detects the ungrab attempt and sends an Ungrab command to the remote VDIagent 124. This command can be sent via the control message channel inone embodiment.

VDI client 134 receives notification of the Ungrab command and sends aDnD RPC (remote procedure call) message (i.e., a DnD command message) toVDI agent 124 to detect the DnD. VDI agent 124 then moves the detectwindow to the target positon and begins a valid DnD process. VDI agent124 sends a DnD RPC message to VDI client 134 to notify “Drag Enter” andVDI client 134 sends a command such as“allowButtonDownMotionUngrab=true” to trigger the ungrab action. VDIclient 134 then starts a new thread to begin the client side DnDoperation.

For remote applications 126, a seamless window captures the mouse eventsby itself instead of the RMKS process, so the remote application 126also needs to handle the “ungrab.” First, the remote application 126sets a “Dragging” flag when “Mouse Move” is detected with any mousebutton being currently held down by a user. Then, the seamless windowdetermines whether the action is a drag-in or a drag-out. If it is adrag-out, application 126 notifies VDI agent 124 to move a detectionwindow and start the agent-to-client DnD process.

In some embodiments, the data transfer for the DnD process can happen oneither the CDR channel or the control message channel. For example, ifthe object to be transferred is small, the object can be sent on thecontrol message channel along with the drag and drop commands. If alarger object is being sent, the CDR channel can be used which issuitable for large data transfers. In addition, in some embodiments datasize control capability is provided for each channel.

In some embodiments, when files or other objects are being copied fromVDI client 134 to VDI agent 124, a parent folder where the draggedfiles/objects are located at client device 104 is shared to VDI agent124. However, for security reasons, it may not be desirable for otherfiles and subfolders in the parent folder to be shown to or accessed byVDI agent 124. To provide security, an access rule can be defined, suchas a whitelist of files/objects/subfolders/etc. that VDI agent 124 isallowed to access. If the request from VDI agent 124 is not for anobject in the whitelist, the request is rejected by VDI client 134. Inaddition, when VDI agent 124 queries information for the shared folder,the information for the objects not in the whitelist can be filtered byVDI client 134 so that VDI agent 124 does not know of their existence.

While support for dragging and dropping a single format of data, such asfiles, is described above, embodiments described herein also supportdragging and dropping mixed formats of data. For example, text, richtext, images, and other content can also be dragged and dropped, eitherindividually or mixed together. In one embodiment, when this content isdragged and dropped, both the control message and the data aretransmitted through the control message channel. In another embodiment,control messages are transmitted through the control message channel andfiles are transmitted through the CDR channel.

With support of DnD for multiple formats (text, images, etc.), DnDcontrols for specific formats are implemented in some embodiments. Thatis, settings can be implemented that allow filtering of the variousformats. As a default, all formats can be allowed to be dragged anddropped in both directions. A user interface at client device 104 allowsa user to enable or disable DnD for each specific format. The user couldalso enable or disable DnD in one direction or both directions for anyparticular format. The user interface allows a user to fully customizethe options for size and format restrictions on dragged and droppedobjects.

Similar to the format controls, a size control can be implemented viathe user interface at client device 104. If dragged content exceeds apreset size threshold, the drag operation can be abandoned. An errormessage is displayed to the user notifying the user of the abandonedoperation in one embodiment. In other embodiments, the dragged contentcan be truncated or filtered, so that a portion of the DnD is completedthat does not exceed the size threshold. For example, some of the filesor other content will be transmitted, up to the size threshold, whilethe rest of the files or content will not be transmitted. The userinterface can allow the user to set the size threshold to anyappropriate value, whether it is in bytes, kilobytes, megabytes, orgigabytes. The user can also set no size threshold. Size thresholds canalso be set separately for different file formats. For example, a firstsize threshold can apply to data in text format, while a second sizethreshold can apply to data in image format. Any number of sizethresholds can be implemented to apply to the various data formats.

Negotiation and control of size thresholds and format restrictionsbetween a VDI client 134 and an agent, such as VDI agent 124, can beimplemented in numerous ways. Negotiation and control includes threeaspects. VDI agent 124 and VDI client 134 retrieve the controls from aregistry or configuration separately and then negotiate with one anotherto implement the final capability. Then the negotiated capability is setin the appropriate component, either VDI client 134 or VDI agent 124 orboth. Finally, the checkpoint to implement the control is added. In oneembodiment, the checkpoints can be placed in a DnD Drop Target Object onthe client or agent side (such as DnD Drop Target 214 and/or DnD DropTarget 228 described above with respect to FIGS. 2A and 2B). Thecheckpoint can be implemented when the drag is initiated in oneembodiment.

Size controls are implemented and applied based on the format of thedragged objects as described above. If a user drags a similar type ofdata from different applications, the format of the data may bedifferent. For example, if a user drags an image from Microsoft® Paint,the data format in OLE is image. Conversely, if the same image isinserted into a Microsoft® Word document and then dragged, the dataformats in OLE are image and HTML. If the image is dragged from aWordPad document, the format is Rich Text.

In addition, for the same piece of content, the size on disk of thecontent and the size of the content stored in OLE may be different.Different image formats (JPEG, BMP, PNG, etc.) also result in differentsizes on disk. Because clients and agents from embodiments describedherein retrieve data from OLE for DnD operations, the clients and agentsdo not have information regarding the source of the data (i.e., an imageor a document) and also do not have information regarding the format ofthe data stored on the disk. Also, the same object may have differentsizes in different operating systems.

Because of this unknown information, size controls are performed on theformat that OLE provides in one embodiment. The actual format of thedata outside of OLE is not considered. In addition, in one embodimentherein, the size controls are implemented based on the size of the datastored in a clipboard structure instead of the size stored on the diskor the size represented by OLE.

A number of strategies may be implemented to implement size controls.For example, if an image exceeds the size threshold, the entire image isabandoned. A user can be notified via a user interface on client device104 if the DnD operation is abandoned in one embodiment. As anotherexample, for Rich Text, HTML, and other formats, plain text is providedalong with the original format for a drag operation. If the draggingsize exceeds the size threshold, the formatting and style information isdiscarded, and the plain text is truncated according to the sizethreshold (if necessary) and then copied to the drop target.

As a third example, if multiple formats are retrieved from OLE during aDnD operation, the formats can be checked one by one by priority. In oneembodiment, text has a higher priority than images, which in turn have ahigher priority than HTML. The size of each format is calculated to seeif it should be abandoned based on the leftover size remainingunderneath the threshold after subtracting the total size of the higherpriority formats. Any suitable priority of formats may be used in otherembodiments.

For DnD of files and folders, size control introduces otherconsiderations. For data formats other than files or folders, data isstored in OLE and the size can be derived from OLE data. For files andfolders, only the path names of the files and folders are stored in OLE.Therefore the size has to be queried separately, which may take a longtime if the user dragged and dropped a large number of files or folders.Also, if the size exceeds the size threshold, the DnD can be rejected orpartially completed. Because of these different considerations, threeimplementations are described herein.

First, the size control can occur after the drag action is performed,whereby some of the files and/or folders are copied up to the sizethreshold. Once the size threshold is reached, the remaining filesand/or folders are not copied. A second solution is to implement sizecontrol just before file copying, and some of the files and/or foldersare copied up to the size threshold. A third solution is to implementsize control just before file copying, and the DnD operation is rejectedand a warning is issued to the user if the size exceeds the threshold.Under each of these three implementations, the user experience andperformance of the system may differ. Therefore any of theimplementations may be suitable to employ depending on the desiredapplication.

In some embodiments, content may be dragged and dropped betweendifferent operating systems. For example, a guest OS 122 may comprise aWindows operating system and an OS 132 at a client device 104 maycomprise a Mac operating system. These operating systems have differentmouse coordinate systems. When objects are dragged between a client andan agent, the mouse point should be converted, so that the object isdragged to the correct destination.

For Mac OS, the origin of the mouse coordinates is the bottom leftcorner of the display. For Windows OS, the origin is the upper leftcorner. For a client using Mac OS, the origin point is changed to theupper left corner.

If a user has more than one monitor, the origin point is also differentbetween Mac OS and Windows OS. For Windows OS, one of the monitors isset as the main monitor and the origin point of the overall system isthe upper left corner of the main monitor. For Mac OS, the origin pointis the bottom left corner of all the monitor screens, no matter whichone is the main monitor. That difference is accounted for when theorigin point is changed for a DnD operation.

In some implementations, feedback on the DnD operation (such asaccept/reject) is generated only after the data is received on thetarget side. Therefore, if the data size is large, a long time can passbefore the feedback is received at the source side. In one embodiment,to accelerate feedback, the data type is sent first and an empty dataobject is created on the drop side with a specific data type (text, richtext, image, etc.). Then, the target OLE object (such as DnD drop Target228 in FIGS. 2A and 2B) can send feedback based on the empty dataobject. This implementation can improve the performance of the feedbackoperation.

It should be understood that, for any process described herein, theremay be additional or fewer steps performed in similar or alternativeorders, or in parallel, within the scope of the various embodiments,consistent with the teachings herein, unless otherwise stated. Inembodiments described herein, a technical solution is provided for atechnical problem. In one example embodiment, the technical problem isthat a drag and drop function is not supported in existing virtualdesktop environments. Therefore, a user cannot easily drag and dropfiles or folders from a client to a remote computer or vice versa. Anexample technical solution presented herein is to use two channels toimplement redirection of an operating system event: a first channel totransfer the drag and drop workflow commands between the client and theremote computer and a second channel to transfer the dragged object. Inaddition, various size and format controls can be implemented on thedragged objects.

The various embodiments described herein may employ variouscomputer-implemented operations involving data stored in computersystems. For example, these operations may require physical manipulationof physical quantities—usually, though not necessarily, these quantitiesmay take the form of electrical or magnetic signals, where they orrepresentations of them are capable of being stored, transferred,combined, compared, or otherwise manipulated. Further, suchmanipulations are often referred to in terms, such as producing,identifying, determining, or comparing. Any operations described hereinthat form part of one or more embodiments of the invention may be usefulmachine operations. In addition, one or more embodiments of theinvention also relate to a device or an apparatus for performing theseoperations. The apparatus may be specially constructed for specificrequired purposes, or it may be a general purpose computer selectivelyactivated or configured by a computer program stored in the computer. Inparticular, various general purpose machines may be used with computerprograms written in accordance with the teachings herein, or it may bemore convenient to construct a more specialized apparatus to perform therequired operations.

The various embodiments described herein may be practiced with othercomputer system configurations including hand-held devices,microprocessor systems, microprocessor-based or programmable consumerelectronics, minicomputers, mainframe computers, and the like.

One or more embodiments of the present invention may be implemented asone or more computer programs or as one or more computer program modulesembodied in one or more computer readable media. The term computerreadable medium refers to any data storage device that can store datawhich can thereafter be input to a computer system—computer readablemedia may be based on any existing or subsequently developed technologyfor embodying computer programs in a manner that enables them to be readby a computer. Examples of a computer readable medium include a harddrive, network attached storage (NAS), read-only memory, random-accessmemory (e.g., a flash memory device), a CD (Compact Discs)—CD-ROM, aCD-R, or a CD-RW, a DVD (Digital Versatile Disc), a magnetic tape, andother optical and non-optical data storage devices. The computerreadable medium can also be distributed over a network coupled computersystem so that the computer readable code is stored and executed in adistributed fashion.

Although one or more embodiments of the present invention have beendescribed in some detail for clarity of understanding, it will beapparent that certain changes and modifications may be made within thescope of the claims. Accordingly, the described embodiments are to beconsidered as illustrative and not restrictive, and the scope of theclaims is not to be limited to details given herein, but may be modifiedwithin the scope and equivalents of the claims. In the claims, elementsand/or steps do not imply any particular order of operation, unlessexplicitly stated in the claims.

Virtualization systems in accordance with the various embodiments may beimplemented as hosted embodiments, non-hosted embodiments or asembodiments that tend to blur distinctions between the two, are allenvisioned. Furthermore, various virtualization operations may be whollyor partially implemented in hardware. For example, a hardwareimplementation may employ a look-up table for modification of storageaccess requests to secure non-disk data.

Certain embodiments as described above involve a hardware abstractionlayer on top of a host computer. The hardware abstraction layer allowsmultiple contexts to share the hardware resource. In one embodiment,these contexts are isolated from each other, each having at least a userapplication running therein. The hardware abstraction layer thusprovides benefits of resource isolation and allocation among thecontexts. In the foregoing embodiments, virtual machines are used as anexample for the contexts and hypervisors as an example for the hardwareabstraction layer. As described above, each virtual machine includes aguest operating system in which at least one application runs. It shouldbe noted that these embodiments may also apply to other examples ofcontexts, such as containers not including a guest operating system,referred to herein as “OS-less containers” (see, e.g., www.docker.com).OS-less containers implement operating system-level virtualization,wherein an abstraction layer is provided on top of the kernel of anoperating system on a host computer. The abstraction layer supportsmultiple OS-less containers each including an application and itsdependencies. Each OS-less container runs as an isolated process in userspace on the host operating system and shares the kernel with othercontainers. The OS-less container relies on the kernel's functionalityto make use of resource isolation (CPU, memory, block I/O, network,etc.) and separate namespaces and to completely isolate theapplication's view of the operating environments. By using OS-lesscontainers, resources can be isolated, services restricted, andprocesses provisioned to have a private view of the operating systemwith their own process ID space, file system structure, and networkinterfaces. Multiple containers can share the same kernel, but eachcontainer can be constrained to only use a defined amount of resourcessuch as CPU, memory and I/O. The term “virtualized computing instance”as used herein is meant to encompass both VMs and OS-less containers.

Many variations, modifications, additions, and improvements arepossible, regardless the degree of virtualization. The virtualizationsoftware can therefore include components of a host, console, or guestoperating system that performs virtualization functions. Pluralinstances may be provided for components, operations or structuresdescribed herein as a single instance. Boundaries between variouscomponents, operations and data stores are somewhat arbitrary, andparticular operations are illustrated in the context of specificillustrative configurations. Other allocations of functionality areenvisioned and may fall within the scope of the invention(s). Ingeneral, structures and functionality presented as separate componentsin exemplary configurations may be implemented as a combined structureor component. Similarly, structures and functionality presented as asingle component may be implemented as separate components. These andother variations, modifications, additions, and improvements may fallwithin the scope of the appended claim(s).

We claim:
 1. A method of transferring a file or object between avirtualized desktop infrastructure (VDI) client running on a clientdevice and a remote virtual machine (VM), wherein the remote VM isconnected to the VDI client through a network, the method comprising:receiving, at the client device, an input corresponding to a drag anddrop operation of an object between a local storage of the client deviceand a remote desktop displayed at the client device, the remote desktoprunning on the remote VM; based on the input, transferring one or morecommands corresponding to the drag and drop operation from the clientdevice to the remote VM or from the remote VM to the client device via afirst channel; and based on the input, transferring the object from theclient device to the remote VM or from the remote VM to the clientdevice via a second channel.
 2. The method of claim 1, furthercomprising, based on the input, transferring the object from the clientdevice to the remote VM or from the remote VM to the client device viathe second channel when the size of the object is above a threshold. 3.The method of claim 1, further comprising, based on the input,transferring the object from the client device to the remote VM or fromthe remote VM to the client device via the first channel when the sizeof the object is below a threshold.
 4. The method of claim 1, furthercomprising: sending progress data from the remote VM to the clientdevice via the first channel while the object is transferred.
 5. Themethod of claim 1, wherein receiving the input comprises detectingwhether the object is transferred to the remote desktop at the remote VMor to an application at the remote VM using two or more detectionwindows.
 6. The method of claim 1, wherein the object is transferred toa temporary folder at the remote VM and then copied to a target folder.7. The method of claim 1, wherein a format of the object is detectedduring the drag and drop operation, and transferring the object isblocked based on the format of the object.
 8. The method of claim 1,wherein transferring the object from the client device to the remote VMor from the remote VM to the client device comprises transferring aportion of the object when the size of the object is above thethreshold.
 9. The method of claim 1, wherein the object comprises two ormore data formats, and data in each of the data formats are transferredfrom the client device to the remote VM or from the remote VM to theclient device.
 10. The method of claim 1, wherein transferring theobject from the client device to the remote VM or from the remote VM tothe client device via a second channel when a size of the object isabove a threshold further comprises creating an empty data object at atarget destination before transferring the object.
 11. A non-transitorycomputer-readable medium comprising instructions to be executed in aprocessor of a computer system, the instructions when executed in theprocessor cause the computer system to carry out a method oftransferring a file or object between a virtualized desktopinfrastructure (VDI) client running on a client device and a remotevirtual machine (VM), wherein the remote VM is connected to the VDIclient through a network, the method comprising: receiving, at theclient device, an input corresponding to a drag and drop operation of anobject between a local storage of the client device and a remote desktopdisplayed at the client device, the remote desktop running on the remoteVM; based on the input, transferring one or more commands correspondingto the drag and drop operation from the client device to the remote VMor from the remote VM to the client device via a first channel; andbased on the input, transferring the object from the client device tothe remote VM or from the remote VM to the client device via a secondchannel.
 12. The non-transitory computer-readable medium of claim 11,further comprising, based on the input, transferring the object from theclient device to the remote VM or from the remote VM to the clientdevice via the second channel when the size of the object is above athreshold.
 13. The non-transitory computer-readable medium of claim 11,further comprising, based on the input, transferring the object from theclient device to the remote VM or from the remote VM to the clientdevice via the first channel when the size of the object is below athreshold.
 14. The non-transitory computer-readable medium of claim 11,further comprising: sending progress data from the remote VM to theclient device via the first channel while the object is transferred. 15.The non-transitory computer-readable medium of claim 11, whereinreceiving the input comprises detecting whether the object istransferred to the remote desktop at the remote VM or to an applicationat the remote VM using two or more detection windows.
 16. Thenon-transitory computer-readable medium of claim 11, wherein the objectis transferred to a temporary folder at the remote VM and then copied toa target folder.
 17. The non-transitory computer-readable medium ofclaim 11, wherein a format of the object is detected during the drag anddrop operation, and transferring the object is blocked based on theformat of the object.
 18. The non-transitory computer-readable medium ofclaim 11, wherein transferring the object from the client device to theremote VM or from the remote VM to the client device comprisestransferring a portion of the object when the size of the object isabove the threshold.
 19. The non-transitory computer-readable medium ofclaim 11, wherein the object comprises two or more data formats, anddata in each of the data formats are transferred from the client deviceto the remote VM or from the remote VM to the client device.
 20. Thenon-transitory computer-readable medium of claim 11, whereintransferring the object from the client device to the remote VM or fromthe remote VM to the client device via a second channel when a size ofthe object is above a threshold further comprises creating an empty dataobject at a target destination before transferring the object.